home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.std.c
- Path: blackbush.xlink.net!slsv6bt!news
- From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
- Subject: Re: BoundsChecker and fgets fmalloc problems
- In-Reply-To: bri@primenet.com's message of 18 Mar 1996 12:48:01 -0700
- Message-ID: <KANZE.96Mar19110432@slsvhrt.lts.sel.alcatel.de>
- Sender: news@lts.sel.alcatel.de
- Organization: GABI Software, Sarl.
- References: <4ikelh$gji@nnrp1.news.primenet.com>
- Date: 19 Mar 1996 10:04:31 GMT
-
- In article <4ikelh$gji@nnrp1.news.primenet.com> bri@primenet.com (Brian
- Gregory) writes:
-
- |> I am using Bounds Checker v2.5, and am having a problem finding a
- |> memory leak it is reporting...
-
- |> Example:
-
- |> fgets( szBuf, 799, fpIn );
-
- |> szBuf is an 800 character buffer (pre-sized array)
- |> fpIn IS a valid pointer
- |> no memory is corrupt before the fgets line
- |> The application is a windows app, written in straight C with a large
- |> memory model.
-
- |> The problem is Boundschecker consistently reports memory leaks for the
- |> larger buffer size mallocs contained WITHIN the fgets function...
-
- Is fpIn ever closed? (If it is stdin, it normally won't be.) Most
- implementations of stdio will allocate a large buffer (for buffering
- purposes) on the first IO to the file, and free it when the file is
- closed. If the file is never closed...
-
- All of the memory checkers I'm familiar with (Purify and my own) have
- the possibility to state that certain `leaks' are normal, and shouldn't
- be mentioned.
- --
- James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
- Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
- -- A la recherche d'une activitΘ dans une region francophone
-
-